How to Develop ~IT systemをみんなで作る方法~
from IT技術の全体感
https://gyazo.com/d5fb711a82d8a8f3fe93b719c936d920
ITsystem開発において、IT知識として理解しておくと良いこと
広く深く理解しないと、品質が保てない
プログラミングはコードリーディングが7割
IT技術の進化で「一人でできること」がどんどん増えた
インフラさえ開発者が準備できる時代
Coding部分はここで話さない
概要から理解しよう
Google drive.icon/inteltank/How to Develop
https://gyazo.com/cb9db4ce6dd349c936f9d4ea90bfe84f https://docs.google.com/presentation/d/1ne3pHPJ-PTxiXZJNvDkJyGzqJfJp-OGaXdThQlxgps4/edit#slide=id.gb83e38e90d_0_504
How to Develop オブジェクト指向・マイクロサービス・ドメイン駆動設計
V型モデル
Vモデルで開発プロセスの全体感を抑える
全体→→→個別→→→全体
1サイクルでは「全体が見えている」ことが良い設計に通じる
良い設計とは変更に強いこと
「無制限に」ではない
アジャイル
アジャイルは「とりあえずやってみようぜ」ではない
VUCAな世界でも顧客に価値を「アジャイルソフトウェア開発宣言」
各パーツを必ず「ビジネス」に繋げる
フルサイクルエンジニア
VMとDockerとCloud Computing Service
Dockerはフリーザ
Computerを使い捨てる、開発のspeedが上がる
Public Cloud (AWS,GCP...)で「開発以外」の手間が激減
だからできたIaC
だからできたCD/CI
地雷駆除じゃないservice release
完成したDevOps
コラム)業務改善には全てエンジニアを入れる。という発想
コードリーディングのウェイトと影響調査
マイクロサービス
microserviceはただのsystem分割ではない
ドメイン駆動設計
ドメイン駆動設計で事業部一体となってServiceを作る
モデル化
テスト
https://gyazo.com/919293a656cab80ba883f21a5e0dd871
メモ
「(ソフト|ハード) x (準備|運用)」で全体を整理
https://gyazo.com/8bcece36b0d46c3514577fdaf94c5f2b
Codingを細かく見ていくと…？
どこまでがCD/CIでTestされるか
テスト駆動開発は「テストを楽に」だけじゃない
設計書は「直接」顧客に価値を与えない
設計を書類でまとめることは必要ではない
設計書がない分、一人一人が「長期視点」を持たなければならない
長期視点を仕組みと思想で担保
開発と顧客をできるだけ近づける
ドメイン駆動設計で事業部一体となってServiceを作る
Codingも設計。CodingでのPracticeはIT Systemの全体設計でも有用
地雷駆除じゃないSystem開発
https://gyazo.com/97b268d620a64b9d760fdfcd5209867b
大きな流れ
Vモデルで開発プロセスの全体感を抑える
ソフトウェア開発はリリースしてからが本番
IT Systemは「開発」以外が重労働
Public Cloud (AWS,GCP...)で「開発以外」の手間が激減
フルサイクルエンジニア
Codingも設計
コラム
天才ゲーム開発者「岩田聡」
アジャイルは「とりあえずやってみようぜ」ではない
microserviceはただのsystem分割ではない
優れた手段の効果はsimpleには伝えられない
Systemを理解する3種の神器
System置き換えの時はI/Oだけを見る
AWSだとさらに楽
AWSはServiceが全てRestfulで設計されている
I/Oの情報はjsonで管理している
実際に開発してみる
個人開発（作ってみる）
最低限、TerminalとText EditorがあればProgrammはできる
高性能Text Editor (IDE)で凡ミスを防ぐ
個人開発（releaseしてみる）
ソフトウェア開発はリリースしてからが本番
Computerを使い捨てる、開発のspeedが上がる
Dockerはフリーザ
IT Infraの構築・管理は人じゃなくComputerに任せる時代
team開発で考えてみる
バージョン管理システムでTeam開発を始める
Computerの世界で、「万能な抽象化」は存在しない
読みやすさ(=可読性)を高める
見知らぬ誰かとCollaboration
よく使うSoftwareはほぼopen source
大きくなっても、ガンガン機能追加する
VUCAな世界でも顧客に価値を「アジャイルソフトウェア開発宣言」
変更しやすさ(=保守性)をうむ原則
ドメイン駆動設計で事業部一体となってServiceを作る
品質も維持しつつ、開発スピードも上げる
顧客が求めるものを最短で開発する
補足で伝えたいこと
おもしろコラム
動作するきれいなコード: SeleniumConf Tokyo 2019 基調講演文字起こし+α - t-wadaのブログ
闇のDevOps DevOpsと業績評価 - ところてん - Medium
２つのことを同時に学ばない - ところてん - Medium
不確実性に向き合う働き方「あなたの夏休みの宿題は？」｜広木大地（日本CTO協会理事/レクター取締役）｜note
プログラミングで一番難しいのは「見積もり」だと思う - Qiita
バグのないソフトウェアの作れない理由 - Qiita
DX（デジタルトランスフォーメーション）とはなにか、そして何ではないのか｜Matsumoto Yuki｜note
「ビジネスロジック」とは何か、どう実装するのか - Qiita
なぜオブジェクト指向は難しいのか - Qiita
みんなの参考になりそう
自称IT企業があまりにITを使わずに嫌になって野に下った俺が紹介するWindowsの自動化の方法 - Qiita
(下準備編)世界一丁寧なAWS解説。EC2を利用して、RailsアプリをAWSにあげるまで - Qiita
IT業界で働く者の基礎知識となるクラウドネイティブ とは？ - Qiita
後でまとめたい
おすすめテスト自動化ツール4選 | ソフトウェアテスト・第三者検証ならウェブレッジ
要件定義と要求定義の違い、ご存知ですか？ | 新規事業・イノベーション共創メディア | Battery（バッテリー）
要件定義に関わる言葉の整理と進め方のコツ（要求、要件、仕様、業務要件、システム要件） | | 元外資系コンサルのガラクタ箱
「バッチサイズは小さめに」: ムダの少ない作業の進め方 - Taka Umada - Medium
役割駆動設計で巨大クラスを爆殺する - Qiita
情報システムの障害状況一覧：IPA 独立行政法人 情報処理推進機構
本番環境でやらかしちゃった人 Advent Calendar 2019 - Qiita
git初学者の初めてのチーム開発で気をつける事の備忘録 - Qiita
https://qiita.com/gold-kou/items/7f6a3b46e2781b0dd4a0?utm_content=buffer63e8a&utm_medium=social&utm_source=facebook.com&utm_campaign=buffer
小中高大生にプログラミング教育をしてきて分かったこと - Qiita
データベース列名の名前付け（英単語での）採用例を集めてみた - Qiita
データベースオブジェクトの命名規約 - Qiita
リーダブルコードを読み直したのでまとめてみた - Qiita